Pump infusion system

ABSTRACT

An infusion pump system comprises a pump for infusing a drug into a patient, a storing unit for storing therapy data, drug data, protocol data, profile data, care type data, and feedback data received from said pump and/or other sources including information about particularities of therapies already carried out or currently running, an input unit for selecting therapy data, drug data, profile data, and care type data, an associating unit for associating the selected therapy data, drug data, profile data and care type data provided by said input unit and further adapted to determine based on said association specific protocol data and specific feedback data, wherein said storing unit also stores said association with said specific protocol data and said specific feedback data; and an output unit for outputting said specific protocol data with said specific feedback data.

TECHNICAL FIELD

The present invention relates to an infusion pump system comprising apump adapted to be attached to a patient and to cause infusion of a druginto the patient's body. Further, the infusion pump system can alsocomprise a plurality of pumps.

BACKGROUND

Infusion pumps are used to deliver a selected drug to a patient inaccordance with a specific protocol which defines a specific drugdelivery and application, e.g. with a predetermined rate and apredetermined dose, to a patient. Usually the protocol is programmedinto the infusion pump. Programming and managing infusion pumps can bedifficult in particular since an infusion pump can be programmed inaccordance with different protocols for different therapies anddifferent locations.

In the prior art, infusion pump systems have been developed which useso-called smart pumps and a drug library. The drug library is a databasewhich can be embedded in the pump, in a personal computer and/or in aremote server (e.g., cloud) and is used to provide protocols andassociated soft and hard infusion limits, wherein soft limits can beoverwritten and hard limits cannot be overwritten. The protocols andlimits are given as output to a query to the database by using searchterms such as “therapy”, “drug” and “profile”. These systems allow areduction of medication errors by identifying a therapy which requiresspecific drugs and specific limits and/or by identifying the relevantcare area and patient's attributes. However, in particular in view ofthe huge extent of the drug library which offers a high number of drugs,there remains a question about therapy outcome.

SUMMARY OF THE INVENTION

It is an object of the present invention to provide an improved infusionpump system in order to overcome drawbacks of the prior art.

In order to achieve the above and further objects, according to thepresent invention, there is provided an infusion pump system comprisingat least

a pump adapted to be attached to a patient and to cause infusion of adrug into the patient's body,

a storing unit adapted to store at least a plurality of therapy datarepresenting different therapies, a plurality of drug data representingdifferent drugs, a plurality of protocol data representing differentprotocols each of which defines a specific drug delivery and/orapplication to a patient, a plurality of profile data representingdifferent profiles relating to specificities relevant for a therapy, aplurality of care type data representing specific aspects of therapies,and a plurality of feedback data received from said pump and/or othersources and including information about particularities of therapiesalready carried out or currently running,

an input unit adapted to enable a selection of specific therapy datarepresenting a specific therapy from said plurality of therapy data,specific drug data representing a specific drug from said plurality ofdrug data, specific profile data representing a specific profile fromsaid plurality of profile data, and specific care type data from saidplurality of care type data,

an associating unit adapted to provide an association of the selectedspecific therapy data, the selected specific drug data, the selectedspecific profile data and the selected specific care type data providedby said input unit and further adapted to determine on the basis of saidassociation specific protocol data representing a specific protocol fromsaid plurality of protocol data and specific feedback data representinga specific feedback from said plurality of feedback data, wherein saidstoring unit is further adapted to store said association along withsaid specific protocol data and said specific feedback data, and

an output unit adapted to output said specific protocol data along withsaid specific feedback data.

Accordingly, in the infusion pump system of the present invention, thestoring unit which preferably can include at least one database stores atherapies list, a profile list, a drug list, a protocol list and a caretype list as well as feedback data received from the pump and/or othersources and including information about particularities of therapiesalready carried out or current running. For the selected items“therapy”+“drug”+“profile”+“care type” (to be selected by the inputunit) an association is made by the association unit so as to determineon the basis of this association a specific protocol and a specificfeedback wherein the specific protocol and the specific feedback are theresult and, hence, the output of a search in the storing unit. Theaforementioned association and selection with eventual corrections arealso stored in the storing unit. Finally, the output unit provides theaforementioned result as output, i.e. the specific protocol data alongwith the specific feedback data.

In accordance with the present invention, per each therapy the chosenfeedback also called therapy feedback is provided so as to have avaluable tool to monitor the therapy outcome during the infusion whichin particular may be last long for chronic patients, wherein at the sametime it is allowed the use of a conventional drug library needed forpresent and future pumps to be used in a hospital for everyday's work.So, due to the present invention it is achieved to bridge the words ofambulatory infusion needs with hospital smart pumps and drug library.

A profile can relate to specificities for a therapy which givesdifferent infusion protocols, wherein specificities can be e.g. patientattributes (like age), delivery route attributes (like intravenous orbranchial block), and infusion rates (e.g. morphine infusion rates for achild and an adult are different).

A care type represents specific aspects of therapies and in particularcan be defined as a particular therapy or a sub-category within atherapy like post-operative pain, palliative care, parenteral nutrition,post-operative pain regional, obstetric pain, chemotherapy,antibiotherapy, immunotherapy, primary pulmonary hypertension,concurrent infusions, sequential infusions, etc. and has a monitoringpage to be output with feedback needs according to medical practice.

In the context of the present invention, it is mentioned that the term“drug” covers fluid pharmaceutical substances and other fluidtherapeutic agents of all kinds.

Further, it is to be mentioned that in the infusion pump systemaccording to the present invention not only one pump, but also aplurality of pumps can be used.

Preferably, said input unit is further adapted to enable input ofupdated feedback data for a given therapy, drug, profile and/or caretype, and said storing unit is further adapted to replace currentfeedback data by said updated feedback data for said given therapy,drug, profile and/or care type and/or a current status of said pump. Thestatus of the pump covers pump events of all kinds like “on”, “off”,“start-stop”, “alarm”, “infusion running”, “rate”, “volume infused”,“time to end infusion”, in case a plurality of pumps are used which ofthe pumps are logged in, etc.

In a further preferred embodiment, said output unit is further adaptedto program said pump in accordance with sad specific protocol data andto adjust the programming of the pump in accordance with said feedbackdata. This embodiment provides an essentially full automation of thesystem.

Preferably, said storing unit and said associating unit are included ina remote server, said input unit and said output unit are included insaid pump, and said remote server is connected to said pump. In analternative preferred embodiment, said storing unit, said input unit,said associating unit and said output unit are included in a remoteserver, and said remote server is connected to said pump.

Preferably, there is provided at least a terminal device connected tosaid output unit and having at least a display to indicate the outputfrom said output unit. Alternatively or additionally, the terminaldevice can be connected to said pump and has a display to indicateoperational data of said pump. The terminal device can be a personalcomputer or a notebook or a mobile device like a tablet computer or amobile telephone.

In a further preferred embodiment, said input unit comprises a questionsproviding unit adapted to provide questions regarding the selectedspecific therapy and an answers providing unit adapted to provideanswers to said questions as a feedback. According to a preferredmodification of this embodiment, said questions providing unit isfurther adapted to provide one or several proposed answers of eachquestion, and said answers providing unit is adapted to enable to selecta proposed answer to a question as a feedback, wherein for instance, incase the specific care type data relate to a palliative care pain, thequestions providing unit is adapted to provide at least a question ofvisual analog scale pains score at rest, or, in case the specific caretype data relate to a post-operative pain, the questions providing unitis adapted to provide at least a question of visual analog scale painscore at rest and/or visual analog scale pain score at mobilizationand/or numbness and/or motor blockage and/or satisfaction with regard tothe specific patient. Preferably, the questions providing unit providesquestions to the user who can be a doctor, a nurse or the patient.

In a further preferred embodiment, said storing unit is further adaptedto store a plurality of nutrient type data representing different typesof nutrient and a plurality of nutrient content data representingdifferent contents of nutrient, wherein specific nutrient content datarepresenting a specific content of nutrient from said plurality ofnutrient content data for specific nutrient type data representing aspecific type of nutrient from said plurality of nutrient type data arelinked to specific therapy data representing a specific therapy fromsaid plurality of therapy data and to specific drug data representing aspecific drug from said plurality of drug data wherein a nutrientcontent is usually defined in kCal/ml (i.e. per volume unit).

According to a preferred modification of the aforementioned embodiment,said input unit is further adapted to enable an input of at leasttherapy data and drug data for storing in said storing unit, in case thespecific care type data relate to an enteral or parenteral nutrition,said input unit is further adapted to enable an input of nutrient typedata and nutrient content data for storing in said storing unit, andsaid output unit is further adapted to output specific nutrient contentdata, in particular per time unit, in accordance with the selectedspecific therapy and drug data. Accordingly, the input unit is not onlyadapted to enable a selection of specific items by the user, but also tobe used by a doctor or a similar expert at setup of a therapy and anassociated drug library. In case the input unit comprises theaforementioned questions providing unit, the questions providing unit isadapted to provide at least a question of nutrition content data for anynutrition type data when inputting therapy data and drug data. Further,for outputting in particular as a graph, during or after infusion, thespecific nutrient content data should be preferably transferred fromkCal per volume unit to kCal per time unit for displaying as a graph.

In a further preferred embodiment, said plurality of drug data includesdata representing desired safety limits for a stored drug, in particularin accordance with specific protocol data. So, limits, preferably softand hard limits, can be given in a drug library for the protocol data

In a further preferred embodiment, said storing unit is further adaptedto store a plurality of patient category data which differ from eachother at least with regard of gender, age, bodyweight and diseaseseverity, wherein, in accordance with specific therapy data representinga specific therapy from said plurality of therapy data and further inaccordance with specific patient category data representing a specificpatient category from said plurality of patient category data, specificprotocol data representing one or more specific protocols from saidplurality of protocol data are linked to specific profile datarepresenting a specific profile from said plurality of profile data. Inthe light of the 5R rule (safety check prior to infusion: right patient& right drug & right protocol & right time to infuse & right deliveryroute), according to the present invention, three of the five items ofthe 5R rule, i.e. right drug & right protocol & right delivery route arestored in the drug library, whereas the remaining two items, i.e. rightpatient & right time to infuse are left for a care plan and infusionorder time to associate.

Preferably, said output unit is further adapted to create a monitoringpage defined by care type data and feedback data and adapted to be shownon a display. So, care type and feedback define a monitoring pagespecific to the feedback needs. The display can be provided at saidoutput unit or at the aforementioned terminal device.

In a further preferred embodiment, said associating unit is furtheradapted to associate protocol data representing several differentspecific protocols to therapy data representing one or more specifictherapies. So, multiple protocols can be associated to some therapieswhich in particular is useful for chronic patients at home using a fewstandard protocols.

In a further preferred embodiment, said storing unit is further adaptedto store a plurality of care area data representing different careareas, said input unit is further adapted to enable a selection ofspecific care area data representing a specific care area from saidplurality of care area data, and said associating unit is furtheradapted to additionally incorporate the selected specific care area datainto said association. Care areas are specialized departments orportions of a hospital like intensive care unit, operational room orward. Care areas in hospitals are mostly to be seen in correlation witha therapy, since mostly care areas are specialized and dedicated for aspecific therapy so that care areas might be considered to be similar totherapies in the search or construction of a drug library. In apreferred modification of this embodiment, said associating unit isfurther adapted to associate protocol data representing specificconcurrent and sequential protocols to therapy data representing one ormore specific therapies, drug data representing one or more specificdrugs and care area data representing one or more care areas.Accordingly, concurrent and sequential protocols can be linked to sometherapies, drugs and care areas, wherein concurrent are protocols formany pumps carrying out infusion at one bed in particular in intensivecare units or operating rooms and sequential are protocols that run oneafter the other like in chemotherapy or piggyback infusions.

In a further preferred embodiment, said storing unit is further adaptedto store a plurality of alarm data representing different types and/orlevels of an alarm, said associating unit is further adapted todetermine on the basis of said association specific alarm datarepresenting one or more specific alarms from said plurality of alarmdata, and said output unit is further adapted to output said specificalarm data. According to a preferred modification of this embodiment,said plurality of alarm data include pump alarm data representingdifferent pump related alarms. According to a still further preferredmodification of this embodiment, said plurality of feedback data includeocclusion alarm data received from said pump and indicating a temporaryinterrupt of operation of said pump, said plurality of alarm datainclude catheter blockage alarm data, said association unit is furtheradapted to determine said catheter blockage alarm data from saidplurality of alarm data in case said specific feedback data includes apredetermined number of occlusion alarm data indicating a predeterminednumber of temporary interrupts of operation of said pump within apredetermined time period, and said output unit is further adapted tooutput said catheter blockage alarm data. In case there are a lot ofocclusion alarms where the pump stops, then the pressure drops, andafter an occlusion setup the pump restarts automatically and possiblyafter sometime occludes again, this is clinically an indication ofcatheter blockage.

The catheter blockage alarm data can be used not only as a warning abouta current catheter blockage, but also for statistic purposes.

In a still further preferred embodiment, said storing unit is furtheradapted to store a plurality of feedback level data representingdifferent levels for feedback data, and said associating unit is furtheradapted to determine on the basis of said association specific feedbacklevel data representing a specific level from said plurality of feedbacklevel data.

The present invention is solving the problem of medication errorprevention also using a drug library but associated with means toimprove the therapy through monitoring infusion therapy outcome andtherapy adjustment. The former is more needed for mainstream infusionswhile the latter is needed in some longer term therapies likepost-operative and palliative care analgesia, parenteral nutrition,immunotherapy, Parkinson's disease and others. The present invention isunifying the ambulatory and bedside infusion pump worlds that canpotentially be served by a single pump and a backbone IT system.

Hospitals usually assign a therapy to a patient, starting at thehospital and at some point going external so that a home care providercontinues therapy, and there is a need to share drug libraries andtherapy feedback through networks. According to the present invention,assigned are health institutions such as hospitals, care areas withinhospitals, and external home care providers, communicating through thesame backbone IT system so that a hospital defined therapy andprescription is transferred with its limits and monitoring preferencesto home care provider.

So, it is an aim of the present invention to provide an improved remoteinfusion therapy management system for interconnected devices as afurther advancement of above prior art, serving both hospital and homecare approaches, integrating drug libraries, protocol libraries, andtherapy feedback parameters libraries, for safety ease of use and bettertherapy outcome. The present invention shall define alarms calledtherapy alarms that do not come from the pump itself, but from potentialuser health nuisance, discomfort or threats or a time in a therapy thatneeds protocol adjustment as for example response to high pain level, oraccessories like catheters needing inspection to avoid complications. Sothe present invention provides means on the server to define suchtherapy feedback alarm levels and means to define therapy feedbackqualitative or quantitative metrics. Further, it is an aim of presentinvention to provide multiple protocol management and monitoringdifferent infusions combined, such as for drug volume monitoringfacility so that in parenteral nutrition, hydration, and TPN or separatelipids and other nutrients are monitored in a timeline for therapymonitoring. Hydration and different nutrients are infused through a pumpor different pumps at different times, but all patient related dataconcerning his intake can be shown on one display.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a schematic block diagram depiction of an infusion pumpsystem according to a preferred embodiment of the present invention;

FIG. 2 schematically shows a block diagram depiction of some componentsof the system of FIG. 1 in greater detail;

FIGS. 3a to 3g show block diagrams in terms of somewhat like flow chartsfor illustrating the function of the system of FIG. 1; and

FIGS. 4a to 4i illustrate examples of pages and windows to be shown on adisplay of a computer and/or a mobile device.

DESCRIPTION OF THE PREFERRED EMBODIMENT

An infusion pump system according to a preferred embodiment of thepresent invention is schematically shown as a block diagram depiction inFIG. 1 according to which the system comprises at least a remote server2, infusion pumps 12 (both ambulatory and bedside), and terminal devices41 which are provided for entry of data and for monitoring and, hence,commonly as an input unit and an output unit.

In FIG. 2, the system of FIG. 1 is shown with some components in greaterdetail.

At a point of care 1 schematically shown are a patient 11, the pump 12,a drug bag 13, a nurse 15 and a communication device 16.

In the example shown, the patient 11 is provided with a RFID tag 14which is attached to her/his body and preferably to her/his arm orfinger as indicated in FIG. 2. Alternatively or additionally the patient11 can also be provided with a “bolus” or “distress” button 121 which isattached to her/his body and preferably to her/his arm or finger asindicated in FIG. 2, too.

In the shown embodiment, the pump 12 is configured as a so-calledminiature pump comprising all those features which are necessary forworking as a pump and controlling the pumping function. So, the pump 12includes a control means for controlling the pumping function so as toadjust the dose of drug(s) to be fed into the body of the patient 11 towhich the pump 12 is to be attached.

Further, there is provided a questions providing unit (not shown) forproviding questions regarding the effects of administration of thedrug(s), and recording unit for recording answers to said questions. Thequestions providing unit and the recording unit can be included in thepump 12 and/or in the server 2.

As schematically shown in FIG. 2, the pump 12 is further provided with a“bolus” or “distress” button 121 and some further buttons 122 which areused for inputting answers to the questions after having been created bythe questions providing unit. In the shown embodiment, the pump 12further comprises a display screen 123 for displaying the questions ascreated by the questions providing means, the input answers and furtherdata and messages. So, the questions providing unit, the display screen123 and the button 222 can be considered an input unit or are at leastparts of an input unit (which is not further shown). Moreover, the pump12 includes wired or wireless bi-directional telecommunication means forbeing connected to other units and devices of the system.

In the shown embodiment, the drug bag 13 is provided with a label 131preferably comprising a barcode and an RFID tag 132 and is filled with adrug 133. The drug bag 13 is coupled via a tube or hose (not shown) tothe pump 12 so as to supply the pump 12 with a drug. Like the pump 12,the drug bag 13 is also adapted to be attached to the body of thepatient 11.

Instead of being directly attached to the body of the patient 11, thepump 12 can alternatively be adapted to be attached to the drug bag 13,or according to a further preferred embodiment the pump 12 and the drugbag 13 can define a common unit to be attached to the body of thepatient 11.

In the shown example, the nurse 15 is provided with a tag 17, too, whichis preferably attached to her hand or finger as schematically shown inFIG. 2.

The hand-held mobile device 16 comprises a “bolus” or “distress” button121, a large display screen 161 and can be embodied as a PDA (PersonalDigital Assistant), a smart phone or a tablet personal computer having atelecommunication function. The screen 161 can be used as output unitfor outputting all relevant data. In case the screen 161 is a touchscreen, the screen 161 can also be used as an input unit, in particularfor providing questions and answers to said questions. Thetelecommunication function comprises a short-range as well as along-distance communication ability. So, according to the describedembodiment the hand-held mobile device 16 includes a local area networkinterface for a wireless connection with a pump 12 via a local areanetwork; however, rather than a wireless communication a wiredconnection between the pump 12 and the hand-held mobile device can bealternatively provided. Moreover, the hand-held mobile device 16includes a long range network interface as well so as to communicatewith external remote devices.

Remote from the point of care 1 is provided the server 2 whichcommunicates with the point of care 1 via the internet. The server 2includes at least one database for storing several data which arerelevant for carrying out the several functions of the system asdescribed later in detail. The data base which is provided as a storingunit is shown as a schematic block 2 a in FIG. 1. Further, the server 2includes an associating unit which is shown as an additional schematicblock 2 b in FIG. 1, wherein the function of the associating unit 2 b isdescribed later in greater detail.

Reference numeral “3” denotes a pharmacy which is schematically shown asa block in FIG. 2 and comprises inter alia a computer 33, a drug fillingequipment 34 and a combined barcode label printer and RFID programmer 35for printing out barcode labels and programming the RFID tag 132. Thecomputer 33 includes a telecommunication interface for connection withthe server 2 via the internet. The drug filling equipment 34 and thecombined barcode label printer and RFID programmer 35 are coupled to thecomputer 33. The drug filling equipment 34 is provided for filling adrug bag 13 as schematically indicated in FIG. 2.

As further shown in FIG. 2, the server 2, is also connected via theinternet to a point of remote therapy 4 where a computer 41 is locatedwhich is operated by a physician or doctor 42. The computer 41 alsocomprises a telecommunication interface for the connection with theserver 2 as well as a screen 411 and a keyboard 412. The screen 411 isused as an output unit for outputting all relevant data, whereas thekeyboard 412 is used as input unit for inputting inter alia and, ifrequired, answers to the questions. Further, if required, the screen 411can be used for providing questions and the keyboard 412 for inputtinganswers to the questions.

Further, in any unit of the system which unit is operated by a user, auser interface may be implemented as a hardware and/or softwarecomponent. Preferably, the user interface consists of a visual programrunning on a display of such unit(s). In the embodiment according toFIG. 2, the pump 12, the hand-held mobile device 16 and the computers 33and 41 include such a user interface as a visual program running ontheir display.

During operation of the system, questions are provided by the questionsproviding unit in the pump 12 and/or, if required, at the screen 161 ofthe mobile device 16 and/or at the screen 411 of the computer 41 whichquestions describe e.g. inter alia quantitatively and qualitatively thecondition of mobility, pain etc. According to the kind of list or tableof questions appearing, the user or patient may answer either “yes” or“no” or with a quantitative reference, e.g. by selection from a list ofprescribed types of answers given as e.g.“bad”-“good”-“better”-“excellent” or numbers from “1” to “10”. Anexample of the questions which may be different per used therapy and/orselected drug and of the kind of the corresponding answers is asfollows:

QUESTION ANSWER Pain VAS score 0 to 10 Pain during emotion 0 to 10Extreme numbing yes/no Blockage of movement yes/no Difficulty in walking0 to 10 Activity 0 to 10 Insomnia 0 to 10 Puffing of legations yes/noSatisfaction 0 to 10 Service assessment 0 to 10 Nausea yes/moderate/noVomiting yes/trend/no Diarrhea yes/slight/no

The control unit of the pump 12 is adapted so as to adjust the dose ofthe pharmaceutical substances within predetermined limits according tothe kind of therapy, pharmaceutical substance and/or user, which limitsare preferably different between local and remote adjustment.

Additionally, sensors (not shown) can be attached to the body of thepatient 11 which sensors are adapted to determine therapeutic results orside effects of the therapy due to the infusion of the pharmaceuticalsubstances, wherein the controlling means is adapted to also adjust thedose of drugs in accordance with the output of the sensors. Forinstance, said sensors may be adapted to record convulsion and/or othermeasurable parameters of the user's or patient's condition. Moreover,implantation electrodes can be arranged near or on the relevant nerve(s)or epidermally and provided for quantitative controlling of musclecontraction. In particular, side effects can be identified by placingsensors in an implantable catheter tip as used in many chronic diseasesin the blood stream (to read states such as temperature, blood pressure,glucose, oxygen and ions) or by the pump asking the user aboutconditions such as diarrhea, vomiting and nausea.

The questions providing means is adapted so that the frequency andtiming of the questions is associated with the dosing of thepharmaceutical substances on the user's demand. So, the questionfrequency and their timing can be associated with the pressing of thebutton 121 at the pump 12 which button is provided as a distress buttonor dosing on demand (bolus) from the user or patient.

Additionally or alternatively, the questions may come at a predeterminedtime after an extra bolus administration or rate adjustment, and/or bymeans of an algorithm (preferably consisting of an artificialintelligence algorithm) determining the time after the aforementionedevents (provision of the last questions, pressing the button, change ofinfusion rate or bolus).

The telecommunication means in the pump 12 and the hand-held mobiledevice 16 provide a communication between parts of the pump infusionsystem at the point of care 1 via a wireless low-power consumptionnetwork of a small-range or hard-wired network, and between the point ofcare 1, the server 2, the pharmacy 3 and the point of remote therapy 4via a wireless long-distance network. The hand-held mobile device 16 isprovided e.g. with a communication screen 161 where the questions canappear. In case of a touch screen, a “volume” gradient type graph can beinputted, too. Preferably, the wireless low-power consumption networkhas a BLE (Bluetooth Low Energy) function or any similar function forproviding a low-range regional-personal network. In case of along-distance mobile device, communication links using the TCP/IPprotocol through WiFi, GSM/GPRS/UMTS, WiMax etc. are preferablyprovided.

The display of the mobile devices having a larger battery can be used asa remote display with the benefit of a larger size and color fidelity.

Preferably, the control means of the pump 12 is adapted to adjust thedose of the drug 133 (1.) by means of a programming to be performedlocally or remote by the attending staff, or (2.) by means of a local orremote algorithm of an automatic control wherein the control meanspreferably includes neural networks and/or a PID (Proportional IntegralDifferential) algorithm resulting in a closed loop infusion control inboth aforementioned cases (1.) and (2.). So, the correction of theparameters of the on-demand dosage and, thus, of the infusion can bedone either locally at the pump 12 or via a local connection to thehand-held mobile device 16, or from remote. The pump 12 is programmedfrom the attending staff locally or from remote, or by means of analgorithm of dose correction by using a closed-loop system for providinga feedback. The automatic control system can include neural networksand/or PID algorithms wherein in case of a difference between a desiredtherapy result and a measured or reported current therapy result acorresponding error is generated by the algorithm. Preferably, for eachon-demand dosage the volume of the drug(s) is algorithmically measuredwithout a simultaneous change of the basal infusion rate. Should theautomatic process correct the pump dosage, if a pharmaceutical companyneeds to keep the closed loop infusion control algorithm proprietary,the algorithm can be located in a server under its control and output tothe pump through telecommunication or telemetry.

The server 2 includes at least one database 2 a (FIG. 1) for storingdata regarding therapy, administration of the pharmaceutical substances,configuration of therapy infusion system user interface for all devices,pharmaceutical substances per therapy, user questions per therapy,protocols and enabling options and limits for remote infusion adjustmentper kind of therapy, alarm and alarm enabling configuration, safetycheck configuration, pharmaceutical substance, preparation description,infusion progress and events or actions, and means for transferring atleast a part of said data to said control means, preferably along withat least one pass code, barcode, RFID and/or biometric recognitionelement. Preferably, the control means is adapted to allow the localand/or remote programming within predetermined limits according to thekind of therapy, drug 133 and/or user, which limits are preferablydifferent between local and remote programming.

So, inter alia infusion protocols, events or actions of the pump(s) andsensors, the user's or patient's answers with the time of occurrence,further information of the users, physicians and other attending staffas well as therapies, drugs per therapy, usual and historic protocolsper therapy and physician, safety limits for close or local and remoteprogramming per protocol defining the therapy, drug, patient and routeof communication can be stored in the database of the server.

The questions are initially stored in the server 2 after having beencreated, before the questions will be transferred along with infusionparameters to the pump 12. Then the questions will appear from the pump12 to the user at the point of care 1, in particular to any local areanetwork device, and can be changed from remote or locally via theconnection with the present computer of the attending staff and arespective local monitoring program.

Protocol libraries are also included in the database 2 a of the server 2which is remote located and to be accessed via the internet. So, theprotocol library and further contents of the database 2 a can be easilyshared between several institutions like e.g. different hospitaldivisions and home care providers. Moreover, one and the same pump 12can be used for different treatments by using different protocollibraries or databases. For instance, such a pump can be used foranesthesia pain control on the one day and for parenteral nutrition onanother day by downloading an adequate protocol list from the server 2.Further, a notion of patient centric programming can be introduced: Ifdata regarding drug 133, concentration etc. are stored in the protocolof the database 2 a, all what is needed at the pump 12 is to assign apatient by name or e.g. by an RFID or a barcode, and all are downloadedinto the pump. Then, a nurse 15 just validates the right protocol, andthe rest of the aforementioned safety rights are validated in the samemanner so as to start infusion. As an example, the pump 12 can startinfusion at a hospital and then stopped, so that all data aretransferred to a home care provider who can come with another pumpdownload data and continues infusion at home. Namely, usually a therapystarts in the hospital by using a hospital pump and continues at home byusing a pump which is provided from a home care provider. For such aprocedure, the relevant data about the infusion and the infusion statuslike volume infused or to be infused, lockout time for bolus etc. alongwith the protocol in use and safety options are uploaded from thehospital to the server 2 and downloaded from the server 2 to the pump ofthe home care provider for continuation of infusion in particular byusing the same drug bag 13.

Preferably, the server 2 can comprise an array of interconnectedcomputers (not shown) each of which includes the part of the databasewhich is under the competence of the responsible attending staff oroffice. For instance, the pump 12 and the associated database (includinginter alia medical histories and protocols) can be managed and thecorresponding data can be stored in a server 2 located with a vendor orsales representative in the respective country, in the patients'databases with their medical histories for a treatment being storedtherein, and/or in databases of hospitals and/or home care companies tobe accessed by physicians, nurses and other attending staff. Such dataare retrieved by a user interface, which is installed in the server 2.Since the communication is carried out between medical devices, the useof the international standard protocol “HL-7” is preferred. Composed arethe data for communication with the patient 11 by means of knowncommunication techniques, e.g. via webpages, smart phone, tabletpersonal computer, PDA (Personal Digital Assistant) applications etc.,or with the pump 12. The stages of the therapy, such as prescription,sending to the pharmacy the pharmaceutical substance(s) to be packagedetc., can be part of the pump infusion system or be provided byapplication of another system with which there is a communication.Respectively, alarms from the pump 12 or occurred during the therapy (inparticular through feedback from the sensor 2) can be forwarded to ahospital alarm server provided in the hospital or the home care orrescue company (not shown).

Server web pages can be used by the hospital service or a home-careprovider and include data about patients treated and nurse personnelorganized in groups. So, the nurse 15 who is in charge of the patient 11will receive via telecommunication a message (in particular an SMS)describing a problem encountered with the pump 12 or the treatment, orbe informed that in a given time the drug reservoir must be replaced.From a list of patients, the attending staff can watch the infusion(events and graphs) and therapy progress of each patient in real timeover the internet, with alarms popping up in such list.

Further, a patient monitoring service (not shown) can use and access thedatabase, e.g. via the internet, in order to reveal e.g. the doseinfusion history and the answers to the questions. Images, in particularincluding graphs, can be generated and depicted either locally or at thepump 12, the hand-held mobile device 16 or the large distance mobiledevice or at a local or regional computer or tablet personal computer byusing a local connection. In particular, the data of the pump 12automatically appear on a computer (like e.g. the computer 41 at thepoint of remote therapy 4) or a tablet personal computer (like e.g. themobile device 16 at the point of care 1) of the physician, nurse and/orother attending staff, which enters the local network connected with thepump infusion system with a password exchange according to the safenetwork practice, and can be stored on the computer for furtherprocessing (e.g. data logging). In case the pump 12 is not connected tothe server 2 and a hand-held mobile device 16 of a nurse 15, which isconnected to the server 2 online, passes by the not connected pump 12, aconnection between the pump 12 and the hand-held mobile device 16 can beautomatically established through the local wireless network so thatdata will be immediately exchanged between the pump 12 and the server 2via the hand-held mobile device 16.

Security is ensured with the ascertainment of both the digitalsignatures of the participants of the communication who usually arepatients on the one hand and physicians or nurses on the other hand, aswell as by using a full cycle of information. In the embodiment shown inFIG. 2, the digital signatures are included in the output signals fromthe tags which preferably consist of RFID tags 14, 17 and 132 shown inFIG. 2. As already mentioned above, one of these tags, i.e. the tag 132is provided on the drug bag 13 adjacent to label 131 which partially orcompletely indicates data like therapy, patient, pharmaceuticalsubstance used, infusion parameters and infusion limits, while the samedata are also stored in the RFID. The reading-out from the system orfrom an accessory of the nurse 15, the transfers to the pump 12 and thesystem and also the identification is carried out, if it is the rightpatient 11 who receives the correct medication and infusion protocolregarding the correct disease within the limits allowed, and the correctadministration route, and following the identification the pump 12 ispossibly programmed accordingly, and the infusion to the patient 11 isallowed. The mentioned accessory of the nurse 15 can be a tabletpersonal computer or an RFID reader which can be automatically ormanually connected to the local network of the pump infusion system.

During the therapy or infusion, by pressing the distress button 121 orarising a sensor alarm, questions are sent to the patient and then theanswers are received, and according to said answers a correction of theinfusion is carried out by means of an automatic control or by a remoteaction of the physician 42 at the point of remote therapy 4. Following asuccessful identification of the physician 42, a safe remote programmingis carried out within limits, so that in such a case the physician 42also works as a programmer.

Preferably, the user's or patient's safety is increased by limiting therange or amount of alteration of the initial parameters so as to allowthe pump 12 to be additionally programmed within limits only. Theselimits are initially provided by the pump 12 and transferred to theserver 2 and from the server 2 to the user interface, so that thepatient 11 is prevented from programming outside the limits. Theselimits include lower limits above which the programmer is informed inorder to avoid errors. Further, the limits can be extended in therapiessuch as regional analgesia, where the risk is lower, or narrowed in caseof intravenous or epidural analgesia or other diseases where the risk isgreater. These limits can be set up by the pump if it is programmedpreferably by a so-called “therapy” menu, or by a physician (using amaximum permissions programming code) if the pump 12 does not have anyprogramming regarding therapy and/or drug 133. So, due to these safetylimits implemented in the pump, the infusion is limited in case of aninternet malfunction, wherein these limits are different for differenttherapies, drugs and/or patients. The responsible attending staff(physicians or nurses) has to validate on the pump 12 the limitsreceived from the server 2, before remote programming is allowed. Theinitial therapy protocol and the limits for the therapy, i.e. the limitsof alterations permitted by the protocol, can be programmed by anymeans, e.g. manually at the pump 12, at the hand-held mobile device 16or by downloading through the internet, wherein validation of theattending staff on the display screen 123 of the pump 12 or on thedisplay screen 161 of the hand-held mobile device 16 controlled by thepump 12 is required through the aforementioned safe process. The remoteprogramming, in particular for correction of the current therapy, whiche.g. is carried out by the physician 42 on the computer 41 at the pointof remote therapy 4, is allowed with the aforementioned process onlywithin the validated limits.

So, the pump 12 is preferably provided with the ability to let theattending staff, the automatic pump process or the distant server 2change certain infusion parameters within a predefined limit. Theseparameters can also be changed by the physician over the internet byusing a safe telecommunication or telemetry process as discussed below(in particular cf. lines 13 to 15 of page 23). The method used bymedical personnel is the automatic process of ‘trimming within limits’preset by the physician. The pump 12 is able to observe these limits soas to prevent excessive over- or under-infusion.

The data regarding therapies, drugs per therapy, protocols and safetylimits of local and remote programming per therapy/drug/type of patientcan be, preferably gradually, downloaded from the server 2 to the pump12 for manageability purposes, preferably with fewer choices, as many asthe use of the pump requires, and for the maintenance of a databaseupdated with the latest data.

Although some functions of the system as shown in the FIGS. 1 and 2 havealready been described above, in the following the completefunctionality and operation of the system will be explained withsupplementary reference to the FIGS. 3a to 3 g.

The server 2, which can be in the cloud and via an IP address accessiblefor all terminals like pumps and other interoperable IT systems,incorporates and partially shares with pumps a number of databases andgenerates a number of infusion and therapy monitor and interaction pagesfor distant users of mobile or stationary computing systems. The totalsystem can carry out infusion related IT tasks as conventionally donewith infusion pumps or other hospital IT systems.

Smart pumps as described in US 2016/0051750A1 or EP 2 987 517 A1 can bepaired preferably through RFID or NFC connections with mobile devicessuch as tablets or phones on which specific applications or simplebrowser are running and programmed by them easier, since they have alarge display and touch keyboards and can follow quick technologychanges in the IT field while pumps must be used for a long time withdifficult regulatory wise changes. In case these devices and the serverare class IIB or III certified, there is no need of validation on thepump, or the protocol has to be validated otherwise. The pairingprocedure can be done by approaching the mobile devices to a pump so asto see the available pump serial number (S/N) and ask for an RFID/NFCreading and pairing process or read their barcode serial number (S/N) orthrough WiFi signal strength sniffing (cf. US 2015/0151051 A1 or EP 2881 875 A1) of both the pump and the mobile device, so that in case ofsimilar antenna signal strengths i.e. a geolocation pattern is found bythe server to show pumps in vicinity available to be paired with.

The pumps 12 of the system also have RFID/NFC and barcode readers (notshown) integrated so that they can directly scan a patient's bracelet orface photo and medication.

But such task can also be done by a suitable app in the computer devices16 and 41, and the information is then sent to the server and associatedto the pump paired with the device. Medication safety is assured if thepump 12 and the drug bag or medication reservoir 13 are connected with ashort upstream tubing or without the provision of any upstream tubing,and barcodes of both the pump and the medication are read in a shorttime sequence.

The server 2 through its continuously updated drug library associates adrug name, concentration and expiry date to a barcode identification(ID) number, or the pump can do the same by download from a drug librarywhich is updated regularly by the server 2. In case of providing an RFIDon the reservoir, a 100% safety is assured as described in US2016/0051750 A1 or EP 2 987 517 A1.

The scanned patient ID or facial photo (from pump or mobile device)enables to give from a patients' database (interoperability withhospital IT systems) provided in the server 2 his name, age and weightor body surface area (BSA) that are sent back to the pump andapp/browser.

So, with a procedure of pump itself scanning patient and medication orscanning from an app and pairing with one or more pumps, and with theserver and pump databases interpreting IDs to names and data, an app andpump show the name of a patient, who will receive infusion, his therapyand feedback specification as described below, age qualifier, weight andBSA for dose calculation, medication name, concentration to calculatedose in mg/Kg/min, expiry date to avoid wrong administration, deliveryroute, delivery time, and protocol if available in the database(interoperability with hospital IT systems) and not programmed on sitethrough the mobile device or pump itself. A complete procedure accordingto the 5R rule (right patient, right drug, right dosing, rightapplication, right time) is facilitated by the connected systemaccording to the described embodiment. The app preferably does not havea programming menu itself, but receives programming pages from theserver. The encrypted security is SSL assured both from the pump andapps, and furthermore data are exchanged with a methodology explained inU.S. Pat. No. 8,551,038 B2 or EP 2 410 448 A1, wherein data go from afirst location (one computer or pump) to a second location (anothercomputer or pump) and reflection data are sent back to the firstlocation after logging and reading log, then compared to initial data atthe first location and sending an identical confirmation to the secondlocation. This results in a higher security than a simple CRC and singletransmission as explained in above prior art.

Conventional smart infusion pumps use so called drug libraries to reducemedication errors defining limits of infusion parameters per drug andpatient or therapy characteristics. Categorization helps a databasesearch to reduce drugs or infusion profiles from a big list to amanageable one and to associate patient characteristics for a giventherapy to a correct infusion profile.

So, a drug library and its search categorization has the form of Therapyor Care Area>Drug>Qualifier or Profile (age, weight, therapy severity,infusion site, infusion specificity) and the output of the drug librarysearch gives limits of protocol parameters for programming and eventualtitration or reprogramming. These limits are soft if they can be overrunafter simple warning, or hard if they cannot.

The present invention as inventive step associates the abovecategorization “Therapy or Care Area>Drug>Qualifier or Profile” with anon-screen remote monitoring per therapy so as to display therapyspecific feedback means for therapy monitoring. This is done by theassociating unit 2 b integrated in the server 2 as schematically shownin FIG. 1. So, it is more a therapy telemedicine system than a classicdrug library, very useful in home care settings where the patient is farfrom his caregiver. The drug library can be accessed also with a drug IDnumber just scanned from a barcode or RFID to retrieve drug name and allrelated safety data and eventually therapies to be used for as a reverseway to read the drug library database. It provides drug complianceinformation to medical personnel, regarding quantity infused, infusiontime (displayed as a graph), delivery route, drug type and therapyfeedback like bolus button press, sensor feedback and answer toquestions.

So, the drug library database structure comprises links between:

Medication ID No. as read on barcode—Drug Name—Concentration—ExpiryDate—Therapy —Therapy Feedback means—Patient Qualifier or Profile (age,BSA, weight, severity of illness, infusion site, infusion specificity).It needs scanning of both patient and drug data to work, or patient dataare input by a user if needed.

A drug incompatibilities database checks multiple concurrent infusionsfor allowance. Some drugs should not be infused at same time withothers; this knowledge is put in said specific database to checkconcurrent protocols.

The connected pumps 12 according to the present application send data toa server as therapy feedback, as programmed with the above associationof therapy specifiers, i.e. output per query of the new advanced druglibrary according to the present invention.

For example, in parenteral nutrition:

In the drug library there is a selection

Care Area=Parenteral Nutrition and associated therapy monitoringParenteral Nutrition

Drug=TPN

Profile=adult

Associated with the patient's name, there is a protocol for eachcategory of his nutrition, total parenteral nutrition (TPN), hydration,etc. taken in different days months or years and pressure of itscatheter to identify possible implantable catheter obstruction. All thisis a valuable therapy feedback to the therapist, collected from theserver and pump, placed in a database in association with the patient'sname and pump history.

In “Parenteral Nutrition” therapy monitoring page as programmed inaccordance with scenario 2 as described at the end of the specification(cf. page 44) and to be displayed e.g. on the screen 411 of the computer41 (wherein such a screen has the function of an output unit) for thispatient, it is shown a historic infusion rate per nutrition type overmore than one infusion, even more than a year where in most cases thepatient is a chronic patient, a downstream pump pressure graph togetherwith an infusion graph versus time and warnings if pressure has somecharacteristics that may cause catheter blockage, all drug volumes andnutrient content, i.e. hydration or TPN, or other, weight graph (from aconnected weight scale) and a kCal/time per nutrient graph so that thedoctor can on one page have all relevant information over all the time,wherein all infusions are sequenced on a time graph, to conduct therapymanagement of the patient.

On a “Palliative Care Analgesia” therapy monitoring page to be displayede.g. on the screen 411 of the computer 41 (wherein such a screen has thefunction of an output unit), associated to palliative care therapy druglibrary query, a VAS pain scale of a patient is shown and pain levelsabove a limit (from the drug library) have different color so to alarmfor therapy adjustment. The infusion pump is asking a pain scalequestion on the pump, and the corresponding answer is reported to theserver. An infusion graph and bolus given over it and statistics of % ofbolus asked divided by bolus given are displayed on a patient's therapypage provided by the server 2.

On a “Post-Operative Analgesia” therapy page as programmed according toscenario 1 described at the end of the specification (cf. page 43) andto be displayed e.g. on the screen 411 of the computer 41 (wherein sucha screen has the function of an output unit), several questions formotor blockage etc. are shown with the answers from the patient on theinfusion pump, so that the doctor can increase or reduce analgesiadepending on motor block age behavior. An infusion graph and bolus givenover it are displayed.

On a “Chemotherapy” page to be displayed e.g. on the screen 411 of thecomputer 41 (wherein such a screen has the function of an output unit),it is shown drugs and drug sequence as delivered, and also answers toquestions such as “vomiting” and other side effects.

On a “Parkinson's” therapy page to be displayed e.g. on the screen 411of the computer 41 (wherein such a screen has the function of an outputunit), patient kinetic sensors (accelerometers) report tremor, normal orLevodopa Induced Dyskinesia LID, or Bradykinesia, and also specifickinetic tests, so that the doctor can adjust therapy. In such case, allkinetic artificial intelligence logic is based on the server whichanalyses raw data from sensors transmitted through the internet.

On a “Diabetes” page to be displayed e.g. on the screen 411 of thecomputer 41 (wherein such a screen has the function of an output unit),infusion rate and bolus are displayed versus time at one level, andglucose monitoring is displayed in another level.

A therapist's monitoring page to be displayed e.g. on the screen 411 ofthe computer 41 (wherein such a screen has the function of an outputunit) may have a list of his patients, their therapy and pump serialnumber(s) (SN), and pending alarm from the pump itself indicating lowbattery or near end reservoir, or from the server through collectedfeedback questions or qualitative analysis of data according to an alarmrule put on the therapy specification page. So, an alarm ischaracterized by a color for immediate attention like a stop of infusionor other color for pre-alarm like a pain level of patient above a limit.The alarm can be acknowledged by the doctor so that it exits from thealarm list. The server can send a text message to the medical personnelin charge of the patient (like home care nurse) with alarm, so that atherapy correction is done as soon as possible. The alarm can be alsosent to be displayed on interoperable hospital alarm monitors. Thealarms are displayed on the patient's therapy monitoring page andpatient alarm list. Alarms can be issued when a determined threshold isreached, but also from statistical evaluation of data, for example ashow many times a threshold has been reached in a time period. So apre-alarm can become an alarm from its frequency of occurrence or othermore complex statistical evaluation of data in the database.

Furthermore, in view of a therapy feedback, since the system monitoringhas pumps and monitors interoperable, the drug library can have a fieldfor third party alarm actions. In case the patient is having low bloodpressure or bradycardia or tachycardia or stop, for a given drug, thepump can run an alarm protocol for the alarm type and drug beinginfused, so that by means of pre-configured actions in the drug librarya pump does a robotic infusion preventing that an anesthesiologist inpanic may not act correctly and with best speed for so many pumpsinfusing. These death preventing actions may be discussed and decided asbest practices by the doctors and put in the drug library feedbacksection and alarm case robotic infusion protocol downloaded into thepump upfront together with normal infusion protocol.

On a patient's therapy watch page to be displayed e.g. on the screen 411of the computer 41 (wherein such a screen has the function of an outputunit) it is also shown the location of the pump and, hence, of thepatient (very useful in pediatric clinics where kids run everywhere),but also at alarm list page the location is displayed aside. Thelocation is determined by WiFi alone or WiFi and GSM signal strengthsrecording and assignment of a location to a bundle of strengths andantennas, and preferably displayed on Google maps as disclosed in US201570151051 A1 or EP 2 881 875 A1.

In many times, an infusion is initiated at a hospital, and then thetherapy continued with several infusions by a home care provider.According to the present invention it is specified which home careprovider from a list is going to care a patient after leaving thehospital so that there remains access of the hospital drug librarysection limited for the patient, thus resulting in having the same errorprevention in therapy continuation. There are no rights to write intothe drug library, but there are only rights to use contents for thecommon patient.

The service is accessible to terminals like the computer 41 at the pointof remote therapy 4 via internet basically by means of a cloud servicefor both setup and monitoring, while all pumps are connecting to thesame server to a socket with TCP/IP protocol. Pumps are storing historicand user feedback (answers to questions) data internally as long aconnection is interrupted and sends them when connection is restored.Normally pumps send status information every 5 minutes or so and alarminformation immediately on the event. So, the server 2 reflects theactual infusion status and patient feedback through devices as a bolusbutton or a measuring device such as glucose meter, or answers toquestions on said therapy watch page. Connection is done using GSM/GPRSdata connection or WiFi networks. This is an Internet of Things (IoT)system and a cloud service of its own. Server/data centers can belocated in one or more locations. The server 2 stores receivedinformation and doctor actions (like acknowledgments or therapycorrection as infusion rate and protocol change) in a number ofdatabases (one of which is exemplarily shown as block 2 a in FIG. 1).The server 2 may have in a database a local Medical Electronic HealthRecord (MEHR) of patient and Electronic Prescription (EP), while thesystem is interoperable with other MEHR and EP systems.

In U.S. Pat. No. 8,551,038 B2 or EP 1 385 420 B1 and US 2016/0051750 A1or EP 2 987 517 A1 it is described a pharmacy automation so that a drugand also a patient are detected from the infusion pump as well asdownload protocols and limits and eventually alarm protocols accordingto the drug library association as described above. Therefore a completedrug library download onto a pump is not needed for a connected pumpsince more and more speeds and connectivity issues are getting better.This patient centric programming greatly eases programming, since a pumpcan detect a patient and a drug from smart labels and download allpending protocols and infusion in accordance with the 5R rule (rightpatient, right drug, right dosing, right application, right time), sothat a nurse executes the one relevant for the time of infusion. Theprogramming can be performed on the pump itself or on a mobileapplication. A program validation by a nurse on the pump is needed aslong as the server and communication are not fulfilling standards forclass IIB or C medical device safety. In the prior art, programmingstarts with annoying questions like “Continue last infusion?” or whattype of therapy or what kind of protocol, what drug, etc. The presentinvention simplifies the programming menu by guiding the user accordingto scans or communications. For example scan patient's ID with ahandheld miniature pump (cf. US 2016/0051750 A1 or EP 2 987 517 A1),then pump sends patient ID to the server and gets back a prescriptionincluding a programming protocol. Then, the user scans the medicationreservoir, and the pump checks if identical to prescription to allowinfusion (5R check). If no prescription available, the app or pump areguided to a new drug menu, and from the patient's therapy data receivedfrom the server the therapy menu pump gets the location by means of WiFisignal strengths scan (cf. US 2015/0151051 A1 or EP 2 881 875 A1), thecorrect drug and the protocol library to use. Communication is servercentric, both pump and application communicate with server and notbetween them directly.

If there is no scan of the drug and if a previous infusion did not getan End Of Infusion alarm, then the pump asks if the user wants tocontinue the last infusion.

A protocol library is partially in every pump and in a larger extent inthe server. Protocol libraries are categorized also by therapy or carearea and drugs to be infused. There are protocols that are written assuch for a care area, and others that include accumulated experiencefrom many infusion histories. A user can use the one or other option toavoid full manual programming. Especially for multiple pumps on the samepatient as usually used in operating rooms, parallel infusions andtherefore multiple programming are the case, or in cancer protocolssequential infusions from one or more pumps are the case. According tothe present invention, shown protocols are associated to a user withtherapy, the user and his preferences himself, the care area andpreferences (protocol type if not simple one) and a quantifier of a 3dimensional description, with protocols in z axis, parallel infusionprotocols spread in y axis and sequential protocols in x axis. So, sinceall pumps can read their associated reservoir through RFID or barcode,the mobile app facilitating programming reads from the serverdrugs—concentration—exp. date—concurrent or sequential infusion plus allrest of 5R. Only protocols having most of the drugs read are proposed toease programming as an inventive step over prior art (U.S. Pat. No.8,894,631 B2, WO 2016/196098, U.S. Pat. No. 8,172,798 B2). So,sequential drug infusion can be done by several connected pumps or byone pump and several valves (cf. US 2016/0051750 A1 or EP 2 987 517 A1),or all drugs are infused by the same pump one after the other where thesystem starts the infusion of the next drug automatically when theprevious one is ended. Pumps in parallel are normal miniature pumps withfull functionality as standalone (as in the above prior art) connectedon a rack so that the system knows they are functionally connected inparallel or sequence for the same shared patient data that are scannedonly once from any system pump. Another option described in the aboveprior art is to use pumps without display and battery that haveRFID/barcode integrated and a cable connected to a monitor displaymultiple infusions controller.

Further particularities of this preferred embodiment are described asfollows.

Therapies, care areas and drug lists are provided. Further provided is acreation of organization defined therapy categories and care areas (cf.FIG. 3a )(later: therapy categories can be assigned with careproperties). Care areas are mostly used in the prior art for hospitaluse, but for home care therapies and therapy categories are morerelevant to define a drug and a treatment. A creation of theorganization structure is done by defining units, rooms, beds. For eachroom and/or bed the signature of the WiFi signals (level and mac addressreceived from access points) can be associated. The units can beassociated with the defined care areas.

Further provided is a creation and management of an organization druglist (drug name, concentration, reference code) and an association ofparenteral and enteral nutritional fluids with nutrient content in thedrug list (later: is utilized in the presentation of infusion data pernutrient content).

Methods and rules related to patient binding (e.g. allow patientassociation through the pump via a patient list nearby the pump on thepump display or barcode scan), 5R verification process (e.g. drugverification by barcode or RFID scan), operator auditing and security(e.g. require barcode or RFID scan of operator or user PIN), deviceprogramming (e.g. enable auto-programming or second nurse verification)and care plan termination can be defined per care area or therapy.Optionally patient's weight and/or BSA (body surface area used often inoncology drugs) is downloaded from server for dose programming(mg/kg/min) used in hospitals.

Delivery protocols can be defined and organized in a drug library orprotocol library structure (cf. FIG. 3b ). Delivery protocols (besidethe default delivery settings, device settings, programming safetylimits which is known in the state of the art) may includeenable/disable of remote titration, how clinical observations can affectthe delivery automatically (e.g. high CO2 stops morphine delivery), orin case of critical medication special rules for programming andverification like requiring an additional confirmation from a secondclinician on the pump

Each care area or therapy can be associated with a subset of the drugsin the organization drug list as well as with one or more specializationcriteria called profiles.

Each combination of (1.) care area (like ICU or cancer ward) or therapy(like pain) or therapy category (like post-op pain regional), (2.) drug,(3.) patient profile (categorization like child or adult, or type oftreatment like sciatic nerve block), and (4.) pump model can beassociated with one or more delivery protocols and titration limits.

Care areas can optionally reference one or more therapies.

Device settings (e.g. alarm settings) can be defined per care area ortherapy (and optionally per profile or drug if required).

Multiple care areas and/or therapies can be grouped so as to create pumpdrug library files that include all the parameters defined in the systemper care area or therapy. If a care area has been associated with atherapy, all information for this therapy will be included and, hence,presented. Pump drug library files can be downloaded wirelessly orthough wired connection to the pumps.

The system interface for browsing protocols in the drug library dependson whether the first index criterion is “care area” or “profile”.

case 1: Therapy>Profile>Drug

case 2a: Care area>Drug>Profile

case 2b: Care area>Therapy>Profile>Drug

A drug library fulfills only three items of the 5R rule, i.e. right drug& right protocol & right delivery route as a result of a query as givenabove.

In an ambulatory care, the specialization of the therapy is frequentlyneeded. In contrast, in a bedside care use scenario, the care area israrely required to be specialized. However, in a bedside use scenario,there could be a need for differentiation of the delivery protocols forspecific drugs and the profile selection after drug has been selected inaccordance with answers to this need.

In specific ambulatory therapies like parenteral nutrition, the patientmay be prescribed with different medications or fluids. In these cases,the caregiver or the patient may have to switch between few deliveryprotocols. In this case, a simpler mechanism than the drug library isprovided.

For the above cases, in a protocol library, simple ordered lists ofdelivery protocols (protocol groups) can be created, containing one ormore delivery protocols for specific patient categories (cf. FIG. 3b ).The protocol groups can be optionally associated with a therapy. Forhospital use, protocol groups are associated with concurrent protocols,i.e. protocols to easily program a multiple pump stack that are to runconcurrently like in operating rooms and ICU, or sequentially forseveral medications to be delivered one after the other like inchemotherapy or piggyback infusions.

Delivery protocols can be associated with a drug from the organizationdrug list, and a display name can be associated with each protocol.

The protocol displayed name could be more user friendly, easy tomemorize a name for the patient, simpler than the drug or fluid name(e.g. “Dark yellow” instead of “Dextrose25%+Vitamins”).

Device settings (e.g. alarm settings) can be defined per protocol group.

Protocol group pump files can be created for each protocol group anddownloaded wirelessly or through wired connection to the pumps.

The system interface for browsing protocols in a protocol group issimpler compared with the drug library, since it is a simple list ofnames associated with each delivery protocol. In case a modification isallowed and performed on the pump for a given delivery protocol of theprotocol group, this change persists on the delivery protocol data.

Protocol groups are created for concurrent infusions (multiple pumps atthe same time) or sequential infusions (many drugs through a single pumpone after the other such as those encountered in chemotherapy) to easeprogramming of the pumps.

Care properties predefined in the system are associated with feedbackmechanisms (like as clinical questionnaires or vital signs monitoringdevices).

Predefined or custom questionnaires as feedback mechanism can beassociated with feedback properties that define the triggering mechanism(like trigger time interval or triggering events) and the systeminterface that will appear on a screen. Triggering mechanism can befixed or adaptive based on the answers given. The creation ofquestionnaires, defines questionnaires as an ordered list of questions(customized or predefined) or adaptive flow of questions based on theanswers given with scale i.e. when an alarm is triggered and a list ofavailable triggers as for example bolus request, new infusion, scheduledtimes during infusion etc. Questions can have different format (numeric,ordinal multiple-choice, multiple-choice, free text and the answers areassociated with clinical observation code) and could be mandatory ornot.

Predefined or custom questionnaires are associated with therapycategories or care areas.

Therapy questionnaires configured to appear on the pump user interfacecan be included in the drug library or protocol group pump files anduploaded to the pump or as will be explained below

Alarms are generated by a server subsystem. Observations fromquestionnaires or devices can be linked with alarm means characterizedby one of the alarm condition, alarm priority, alarm model (latching,non-latching, time point event, start only, start-end) further groupedper therapy categories or care areas. A smart alarm system is generatedby a Systems Alarm Rule page, configurable per therapy category or carearea and evaluates data of the care plan, optionally compares them withdata from other similar care plans and generates alarms accordingly.Pump questionnaires are included in the drug library or defined andedited per patient and uploaded for each patient.

Rules per user type and end point type (email, SMS Text message,build-in notification system) for disseminating alarms and notificationsgenerated by the system (devices and server) (cf. FIG. 3e ). SMS andemail notification for alarms may not include patient identificationinformation according to the patient data protection legislation, butcould include a deep link that leads to the specific patient and careplan views of the system that is related to the specific alarm.

Each user can assign himself as “in charge” of the organization or of aspecific user group in order to receive the SMS and/or emailnotifications. Each group can be associated with specific care areas,therapies and/or care plans so that its members receive only alarms andnotifications from these care areas, therapies and/or care plans.

Alarms can be transmitted to HIT systems. Interoperability example basedon integrated health care enterprise alarm communication management orIHE ACM.

Prescribers, homecare providers, nursing providers can be connectedtogether in a health network (cloud environment).

A homecare provider user can create a care plan and associate with theprescriber or prescribing organization. Alternatively, a hospital usercan refer a care plan to a home care provider. All actors involved inthis care plan will have access and be able to manage the care plan.Home care providers can have access to part of hospital therapies(including the part of the drug library) so that they can create careplans according to the hospital protocols. The hospitals can selectwhich therapies would be accessible by the connected homecare providers.

Organization defined therapy categories and care areas can be associatedby the organization with specific care properties. By means of careproperties predefined in the system, the presentation of infusion datain the system and the input means of the care plan of a patient arecontrolled. An example of a care property type is the type of theinfusion therapy (post-operative pain, obstetrics pain, parenteralnutrition, general infusion). Other care property types could be theroute of administration, the catheter type etc.

A creation and control of care plans (cf. FIG. 3c ) for the patient canbe provided which define a monitoring and control session for thespecific patient and groups orders, devices, alarms, infusion and othertherapy data. A care plan and infusion order defines the remaining twoitems of the 5R rule by adding the name of the right patient and theright time to infuse to the contents of the drug library which, asmentioned above, only fulfills the other three items of the 5R rule.

A manual association of a patient care plan can be provided through anapplication interface directly with the care properties in the system orindirectly through the association of the care plan with therapycategories or care areas. Associated therapies or care areas of a givencare plan can be changed based on the therapy status or progress of thehospitalization. Specifically, the care area associated with the careplan can be automatically changed based on location information from thepump or information received from external systems.

Multiple concurrent care plans can be created for a patient. Forexample, a care plan for general infusion will be created for a patientunder surgery, and a new care plan will be created dedicated to the painmanagement.

An automatic creation of care plan can be carried out based on operatoractions on the pump interface for a new patient programming through drugor protocol library. In case the patient identification information isavailable at the point of care, the care plan will be associated withthe given patient, else the care plan will be associated with ananonymous patient at creation and the actual patient can be manuallyassigned through the application interface after creation of the careplan. Multiple infusions and infusion pumps can be automaticallyassociated with a care plan (for care plans defined with care area)based on information about the patient and the care area received fromthe pump.

A manual or automatic association of therapy questionnaires defined inthe system for the selected therapy to the care plan is provided. Thereis an option to terminate the care plan on the pump interface when a newtherapy is selected or when a new patient is selected. The care plan canbe terminated manually by the user through the user interface of theterminals.

Infusion orders (e-prescription) are done through application interface(could be at the point of care through a mobile application interface).A creation of infusion orders in an application interface can be donefrom a scratch or through selecting, copying and editing protocolsdefined in the drug library or protocol library wherein an optionalassociation to a care plan can be provided. In case the prescription isbased on the drug library or protocol library, the safety limits apply.The infusion order includes a part or all of the information for a 5Rverification (including the time to be delivered and route ofadministration). Patient specific delivery programming limits can bedefined in the infusion order for a local (at the pump) and/or remotemodification of the protocol. A special custom formulation of drugs andfluids can be defined in the infusion order. As an example, parenteralnutrition formulation can be defined, and the associated nutrientcontent can be calculated automatically or manually defined. Theinfusion orders can be also automatically entered in the system byexternal HIT systems wherein the interoperability for example can usethe integrated health care enterprise point-of-care infusionverification (IHE PIV) profile. Infusion orders created through thesystem interface could be communicated to external HIT systems. Aninfusion order can be valid for a single or multiple or unlimited numberof infusions, and can define the intervals of the repeating infusions(e.g. 2 infusions per month). Multiple infusion orders can be grouped tobe applied on a single pump as pump protocol group. The infusion orderor pump protocol group can include device settings (like pump alarmsettings) as defined in the system for the related therapy or care areaor protocol group. The infusion orders can have time/completion relationbetween each other. Multiple infusion orders can be created per patientor care plan. There can be provided templates for a quick creation ofmultiple infusion orders that contain the inter-relations of the orders.Those include sequential and concurrent infusion orders for a singlepump or stack of pumps.

Further provided is the printing of barcode and RFID tags for drugscontained in a master drug list or specified in the infusion orders. Alist of medications pending to be dispensed is presented in the userinterface. Each drug prepared and stored in the pharmacy or dispensedfrom the pharmacy is tracked in the system with manual input or by RFIDor barcode scanning.

Pending orders for a patient are shown in a timetable together withinfused and actual infusion status as known in prior art pharmacyorganization.

Further provided is a patient/care plan/infusion order binding to thepump. A patient identification can be done through the application orthe pump interface via manual entry, scanning bar code or RFID tag orpatient photo and recognition or other identification means or selectionfrom an available patient list and if required in combination withinformation received from connected third party HIT systems. Manualpatient care plan or infusion order association with the pump can bedone through the pump interface by selecting the patient from the listof unassociated or active care plans or orders with optionalverification with entering a part or all of the elements of the patientidentification information (e.g. year of birth). The list is transferredfrom the server to the pump. Alternatively, patient, care plan orinfusion order association with the pump can be done by scanning thepatient and/or drug identification information with the pump or withanother terminal device connected to the system. If the terminal deviceis not the pump, the pump ID should be entered or selected manually orby scanning the barcode or RFID of the device.

Further provided is a patient association with a device group. In caseat least an infusion order exists for a patient, an automaticverification of the correct match according to the 5R rule betweenpatient, drug, infusion order and time is performed based on informationprovided from the point of care (drug, patient). An automatic transferof the infusion order(s) to the pump and an automated application of theinfusion order(s) on the pump can be carried out.

In case of a manual pump programming, the program is transmitted to theserver and verified against the related infusion order(s). In case amismatch is detected in the drug, route of administration, time ofinfusion, patient and delivery parameters, an alarm is generated by thesystem. Optionally the pump also displays an alarm and optionally doesnot allow the delivery.

There can be an automatic transfer and application of the questionnairesassociated with the care plan to the associated pump.

The infusion orders may contain information related to device settingsas defined in the application for the specific therapy category. Thedevice can be dissociated from an infusion order or care plan manuallythrough the user interface of the terminals and/or based on identifieddevice location (e.g. if the pump is to be returned to the pool of pumpsor a warehouse) and/or based on a time-out after power off (e.g. 24hours). As expressed, this setting is configurable per care area ortherapy.

Each infusion order is related with the respective infusion (medicationadministration) information received by the device. The compliance ofthe prescription can be automatically checked and presented not only atthe start of the infusion, but throughout the infusion and the therapy.Each medication dispensing event is related with the respective infusion(medication administration) information received by the device allowingtraceability between the dispensed and administered medications.

A main screen “Care view” for all therapies and care areas displays theactive care plans infusion status (drug infused, infusion status,infusion rate) and alarms so as to monitor the therapies (cf. FIG. 3d ).

In the user interface the ongoing care plans of a specific therapy alongwith information relevant to this therapy based on the associated careproperties are presented as therapy views. The user can select thetherapy to access different views (and filter the presented care plans).The ongoing care plans identified by the patient information and therapyare presented as lines and the therapy information as columns of atable. In case of information that is based on aggregation (e.g. numberof patient bolus requested over a period), the relative aggregationrange can be selected by the user (e.g. last 12 hours). The informationpresented in the columns of each therapy can be system default (based onthe care properties) or defined be the user. The user can createcustomized views by selecting the care properties of each custom viewand the columns for each view. The user can define the view that ispresented when the “therapy views” is accessed.

The therapy monitoring screen (cf. FIG. 3d ) for each care plan (cf.FIG. 3c ) depends on the care properties associated with each care plan.

The alarms can be active alarms and/or history alarms.

A patient bolus activity can comprise information about the bolusrequested and the bolus given for the period selected by the user.Trends and aggregated data per day of week for bolus requested or givenper hour, line pressure, delivered drug/fluids can be displayed.

Especially for palliative care the bolus requested or given per hour isdisplayed on the same graph with a horizontal axis representing the hourof the day for a selected period (e.g. a week). This allows the user toidentify a pattern of pain related to the hour of the day. Specificallyfor parenteral nutrition (PN) and enteral nutrition (EN) a breakdown fornutrient elements can be observed, based on the nutrient content thathas been defined for the fluids in the drug list.

Infusions (administered medication) are presented in relation to theprescription to demonstrate the level of prescription adherences in timegraphs and table reports.

The fluid balance of the patient per day or other selected time periodis presented by the infusion data and observations related to thepatient fluid output.

The Infusion timeline view allows to monitor the completed, ongoing andpending/ordered infusions in time. The data from infusions, pendingorders and feedback mechanisms are presented grouped per patient, careplan and order. The user can select and save filters with criteria likecompleted, executing, pending infusions, care area etc. The patientlocation and the summary of active alarms are also displayed. Thedelivered drug can be presented in frames of user selected time windows(e.g. 10 minutes). Alarms can be shown on the floor plan of theorganization (that includes the beds) as room alarms.

As action lists provided can be Alarms (cf. FIG. 3e )—Pending orderslist (ordered by time) —Infusions near end—Pending orders ordered bytime—Questionnaires.

There is a list of alarms that require handling order by descendingpriority and grouped by patient, the infusion remaining time ordered byremaining time, the pending orders ordered by due time, and thequestionnaires that require feedback ordered by time passed from triggertime.

The system allows the creation of custom notes under the context of aspecific care plan. The notes can include a “©” reference in which casethe note is sent as a message to other users including the care plancontext.

The terminal through which an infusion can be programmed canautomatically filter the data presented based on its location (e.g.present only patients close to the terminal).

For a continuous quality improvement (CQI) the pump can send events forexceeding the defined delivery safety limit (hard or soft) and theprogramming method per infusion (auto-verification, drug library,protocol library or manual). The system based on the pump data providesstatistic reports per care area, profile and drug for drug usage, softand hard overrides (including the limit, the attempted value andoverridden or corrected (for soft)), programming method, delays toexecute infusions and responsiveness to address alarms.

Since an access of an operator can be tracked by RFID or barcode oranother identification system, above reports can be provided by theoperator and support the healthcare personnel training and performancemonitoring. Therapy related information and satisfactions scores fromobservations can provide an overview of the care delivered. The CQI datacan be compared with similar data from other organizations, allowing abetter understanding to an organization about the quality of itsoperations.

The user can browse the local drug library or alternatively, since thepump is an alternative terminal of the system, connect to the druglibrary of the system. The user interface can be indicative for browsingthe drug library (cf. FIG. 3b ).

For a device management the system offers to the user of theorganization a real time report about the registered devices withinformation about the software version, drug library version, preventivemaintenance due date, utilization and location. This information canalso be transmitted to third party systems through interoperabilityprofiles. Areas for pump storage and their associated WiFi signature canbe defined. Technical service actions performed on the device likepreventive maintenance or service of a defect can be tracked in thesystem.

A “Find pumps location” menu to be displayed e.g. on the screen 411 ofthe computer 41 (wherein such a screen has the function of an outputunit) shows all departments and care areas where pumps are used orstored, even outside the hospital, (cf. EP 2 881 875 A1 or US2015/0112265 A1) by using a hospital map or Google Maps (for external).

FIGS. 4a to 4i illustrate examples of pages and windows in particular tobe shown on the screen 161 of the mobile device 16 and/or on the screen411 of the computer 41.

FIG. 4a shows a page indicating the patient bolus activity withinformation about the bolus requested and given for a period selected bythe user.

FIG. 4b shows a page including a graph of observations for the bolusrequested and given per hour and the line pressure wherein trends andaggregated data per day of week for the bolus requested and given perhour, the line pressure and the delivered drugs can be determined fromthis graph.

Especially for palliative care, the bolus requested and given per houris displayed on the same graph with the horizontal axis representing thehour of the day for a selected period (e.g. a week) as shown in FIG. 4c, so that the user is allowed to identify a pattern of pain related tothe hour of the day.

FIG. 4d exemplarily illustrates a multiple patient window with therapyviews. In this user interface the ongoing care plans of a specifictherapy along with information relevant to this therapy based on theassociated care properties are presented.

The user can select the therapy to access different views (and filterthe presented care plans). The ongoing care plans identified by thepatient information and therapy are presented as lines and the therapyinformation as columns of a table. In case of information that is basedon aggregation (e.g. number of patient bolus requested over a period)the relative aggregation range can be selected by the user (e.g. last 12hours). The information presented in the columns of each therapy can besystem default (base on the care properties) or defined be the user. Theuser can create custom views by selecting the care properties of eachcustom view and the columns for each view. The user can define the viewthat is presented when the “therapy views” is accessed. The therapymonitoring screen for each care plan depends on the care propertiesassociated with each care plan.

FIG. 4e shows an alarm window indicating active alarms and the historyof alarms.

FIGS. 4f and 4g illustrate parenteral/enteral nutrition pages whereinthe page according to FIG. 4g includes a graph. In particular forparenteral nutrition and enteral nutrition, it must be taken care of abreakdown for nutrition elements based on the nutrient content that hasbeen defined for the fluids in the drug list.

Infusions (administered medication) are presented in relation to theprescription to demonstrate the level of prescription adherences in timegraphs and table reports.

The fluid balance of the patient per day or other selected time periodis presented by the infusion data and observations related to thepatient fluid output as given on the page shown in FIG. 4 h.

FIG. 4i shows a window for monitoring the pump status (for all caretypes).

Finally, as a further example two scenarios are given:

Scenario 1:

Therapy: Peripheral nerve block

Care Type: Post Operative Pain

Profile: Femoral Block

Questions: VAS score Scale 1-10 Alarm @ 6

-   -   Numbness Y/N Alarm @ Y

One Drug of many: Ropivacaine 1 mg/ml

Database gives Protocol: Basal rate 2 ml/h

-   -   Bolus 1 ml    -   Lockout time 10 min    -   Delivery route peripheral nerve    -   Device settings near EOI 3 ml, occ pressure high

Shows: answers to questions, red alarm if activated from levels, pumpfunction/pump alarms and connectivity.

Scenario 2:

Therapy: Parenteral Nutrition

Care Type: Parenteral Nutrition

Profile: Adult

Questions:

One Drug of many: Total Parenteral Nutrition

-   -   Carbohydrates: 7000 Kcal/L    -   Lipids: 3000 Kcal/L    -   Protein: 700 Kcal·L

Database gives Protocol: Basal rate: 160 ml/h

-   -   Feedback: Downstream Pressure Monitoring    -   Occlusions per infusion alarm: 5    -   Occlusions summed time: 3 min    -   Delivery route: IV Central Venous Catheter    -   Device settings: near EOI 10 ml, occ pressure low

Shows: answers to questions, red alarm if activated from levels, pumpfunction/pump alarms and connectivity.

Finally, it should be noted that the above described embodiment is of anexample for implementing the present invention. However, the scope ofthe present invention should not necessarily be limited by the abovedescription, but is defined by the following claims:

1-27. (canceled)
 28. A method for operating an infusion pump system, themethod comprising: attaching a pump to a patient to cause infusion of adrug into the patient's body, the pump further configured to receivetherapy feedback data; storing a plurality of therapy data representingdifferent therapies, a plurality of drug data representing differentdrugs, a plurality of protocol data representing different protocolseach of which defines a specific drug delivery and/or application to apatient, a plurality of profile data representing different profilesrelating to specificities relevant for a therapy, wherein thespecificities relevant for the therapy comprise patient attributes, anddelivery attributes, a plurality of care type data representing specificaspects of therapies, a plurality of alarm data comprising catheterblockage alarm data; identifying the catheter blockage alarm data fromthe plurality of alarm data when a pump feedback data comprises apredetermined number of occlusion alarm data indicating a predeterminednumber of temporary interrupts of operation of the pump within apredetermined time period; receiving a selection of specific therapydata representing a specific therapy from the plurality of therapy data,specific profile data representing a specific profile from the pluralityof profile data, and specific care type data from the plurality of caretype data; generating a catheter blockage alarm when the pump feedbackdata comprises a number of occlusion alarms indicating a number oftemporary interrupts of operation of the pump, the number of occlusionalarms exceeding a threshold number identified in the catheter blockagealarm data; providing an association of the selected specific therapydata, the selected specific profile data and the selected specific caretype data and further adapted to determine on a basis of the associationspecific protocol data representing a specific protocol from theplurality of protocol data and specific therapy feedback datarepresenting a specific therapy feedback from the plurality of therapyfeedback data, as well as to store the association along with thespecific protocol data and the specific therapy feedback data;outputting the specific protocol data along with the specific therapyfeedback data; and programming the pump in accordance with the specificprotocol data and to adjust the programming of the pump in accordancewith the therapy feedback data.
 29. The method of claim 28, furthercomprising: selecting a specific monitoring page format comprisingpredetermined fields, from a plurality of predetermined monitoring pageformats, based on the specific care type data.
 30. The method of claim29, further comprising generating a monitoring page based on thespecific monitoring page format and comprising therapy feedback dataadapted to be shown on a display.
 31. The method of claim 28, furthercomprising storing a plurality of therapy feedback data includinginformation about particularities of therapies already carried out orcurrently running.
 32. The method of claim 28, further comprisingstoring route attributes.
 33. The method of claim 32, wherein the routeattributes comprise at least one of an intravenous block or a branchialblock.
 34. The method of claim 28, further comprising providingquestions regarding the selected specific therapy and providing answersto the questions as therapy feedback.
 35. The method of claim 34,further comprising providing one or several proposed answers of eachquestion, and receiving a proposed answer to a question as therapyfeedback.
 36. The method of claim 35, wherein when the specific caretype data relates to a palliative care pain, and providing at least aquestion of visual analog scale pains score at rest.
 37. An infusionpump system comprising: a pump adapted to be attached to a patient, tocause infusion of a drug into the patient's body, and to receive therapyfeedback data; a processor, communicatively coupled to the pump, andadapted to store a plurality of therapy data representing differenttherapies, a plurality of drug data representing different drugs, aplurality of protocol data representing different protocols each ofwhich defines a specific drug delivery and/or application to a patient,a plurality of profile data representing different profiles relating tospecificities relevant for a therapy, wherein the specificities relevantfor the therapy comprise patient attributes, and delivery attributes, aplurality of care type data representing specific aspects of therapies,a plurality of alarm data comprising catheter blockage alarm datawherein the processor is configured to identify the catheter blockagealarm data from the plurality of alarm data when a pump feedback datacomprises a predetermined number of occlusion alarm data indicating apredetermined number of temporary interrupts of operation of the pumpwithin a predetermined time period; an input unit adapted to receive aselection of specific therapy data representing a specific therapy fromthe plurality of therapy data, specific profile data representing aspecific profile from the plurality of profile data, and specific caretype data from the plurality of care type data, the input unit or theprocessor configured to generate a catheter blockage alarm when the pumpfeedback data comprises a number of occlusion alarms indicating a numberof temporary interrupts of operation of the pump, the number ofocclusion alarms exceeding a threshold number identified in the catheterblockage alarm data; an association unit configured to provide anassociation of the selected specific therapy data, the selected specificprofile data and the selected specific care type data provided by theinput unit and further adapted to determine on a basis of theassociation specific protocol data representing a specific protocol fromthe plurality of protocol data and specific therapy feedback datarepresenting a specific therapy feedback from the plurality of therapyfeedback data, as well as to store the association along with thespecific protocol data and the specific therapy feedback data; an outputunit adapted to output the specific protocol data along with thespecific therapy feedback data, program the pump in accordance with thespecific protocol data and adjust the programming of the pump inaccordance with the therapy feedback data; and a remote server connectedto the pump and configured to store the plurality of therapy data, theplurality of drug data, the plurality of protocol data, and theplurality of profile data and comprising at least one of the associationunit or the output unit.
 38. The system according to claim 37, whereinthe input unit is further adapted to enable input of updated therapyfeedback data for a given therapy, drug, profile and/or care type; andthe processor is further adapted to replace current therapy feedbackdata by the updated therapy feedback data for the given therapy, drug,profile and/or care type and/or a current status of the pump.
 39. Thesystem according to claim 37, wherein the input unit comprises adisplay.
 40. The system according to claim 37, wherein the input unit isat least one of a personal computer, a notebook, a tablet computer, amobile telephone, or a mobile device.
 41. The system according to claim37, wherein the input unit is adapted to provide questions regarding theselected specific therapy and to provide answers to the questions astherapy feedback.
 42. The system according to claim 41, wherein theinput unit is adapted to provide a question of nutrition content datafor any nutrient type data when inputting therapy data.
 43. The systemaccording to claim 37, wherein the processor is further adapted to storea plurality of nutrient type data representing different types ofnutrient and a plurality of nutrient content data representing differentcontents of nutrient, wherein specific nutrient content datarepresenting a specific content of nutrient from the plurality ofnutrient content data for specific nutrient type data representing aspecific type of nutrient from the plurality of nutrient type data arelinked to specific therapy data representing a specific therapy from theplurality of therapy data.
 44. The system according to claim 43, whereinthe input unit is further adapted to enable an input of at least therapydata for storing in the remote server, when the specific care type datarelates to an enteral or parenteral nutrition, the input unit is furtheradapted to enable an input of nutrient type data and nutrient contentdata for storing in the remote server, and the input unit is furtheradapted to output specific nutrient content data, including per timeunit, in accordance with the selected specific therapy.
 45. The systemaccording to claim 37, wherein the remote server stores a plurality ofdrug data representing different drugs and wherein the plurality of drugdata includes data representing desired safety limits for a stored drug,including in accordance with specific protocol data.
 46. The systemaccording to claim 37, wherein the remote server is further adapted tostore a plurality of patient category data which differ from each otherat least with regard to at least one of gender, age, bodyweight, ordisease severity, wherein, specific protocol data representing one ormore specific protocols from the plurality of protocol data andincluding specific time-to-infuse data and/or specific delivery routedata are linked to specific profile data representing a specific profilefrom the plurality of profile data based on specific therapy datarepresenting a specific therapy from the plurality of therapy data andfurther in accordance with specific patient category data representing aspecific patient category from the plurality of patient category data.47. The system according to claim 37, wherein the processor is furtheradapted to store a plurality of care area data representing differentcare areas, and the input unit is further adapted to enable a selectionof specific care area data representing a specific care area from theplurality of care area data, and the processor is further adapted toincorporate the selected specific care area data into the association.